Distributed data store for managing media

ABSTRACT

Described herein are various embodiments of a system for tracking interests in content using a distributed data store. By being “distributed,” there may be multiple different copies of the data store that each hold a portion or all of the data of the data store, with the different copies being continuously, periodically, or occasionally synchronized to ensure that data held in one matches the data held in another, but with no copy of the data store being treated as the official or canonical copy of the data store. The distributed data store may track the interests regarding the content in particular ways, including through storing information identifying the content and identifying interests in the content. The distributed data store may be used to track interests in media, such as to track ownership, management, or royalty interests in media like songs, to provide a mechanism for “Digital Rights Expression” (DRE).

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. § 119(e) to U.S.Provisional Application Ser. No. 62/371,828, titled “Blockchain anchoredformat wrapper” and filed on Aug. 7, 2016, and to U.S. ProvisionalApplication Ser. No. 62/454,750, titled “A format wrapper with tagging,trust, and authority in a blockchain-based tracking system” and filed onFeb. 4, 2017, each of which is herein incorporated by reference in itsentirety.

BACKGROUND 1. Technical Field

Described herein are embodiments of a system for enabling tracking ofinterests in content using a distributed data store of informationregarding the content, including for calculating and storing, in thedistributed data store, a score indicative of a reliability of dataregarding the content in the distributed data store, wherein the scoremay be calculated based on a nature of interactions with the distributeddata store regarding the content and an identity of the interactingparty.

2. Discussion of Related Art

Many different parties may be involved in the creation of media content.For example, a song may be written by multiple people, such as bymultiple people who collaborate in writing the music for the song (e.g.,they may separately or collaboratively write a bass line, a beat, amelody for a part of the song, a harmony for that melody, etc.) andpotentially multiple other people who collaborate in writing lyrics forthe song (e.g., they may separately or collaboratively write verses,choruses, a bridge, etc.). That same song may then be performed bymultiple people, such as singers and musicians who work together in theperformance and may be different from the writers of the song. If a songsamples work of another (e.g., by incorporating a small part of a priorwork), writers and performers of the source song may be credited in thecreation of the song. Further, beyond the writers and performers, theremay be many other people involved in the creation, recording, ordistribution of the song, such as managers, record labels, producers,studio engineers, publishers, and others.

Each of these parties may hold rights in a media content and may be dueroyalties for performances of the media content or for revenues receivedfrom distribution of the media content. Performing Rights Organizations(PROs) may track contribution to a song, to determine who is to receiveroyalties.

SUMMARY

In one embodiment, there is provided a method for maintaining adistributed data store storing information regarding a plurality ofmedia contents and a record of interactions with the plurality of mediacontents. The method comprises determining a reliability of informationinput by a user to the distributed data store. Determining thereliability comprises, in response to determining that the user hasasserted an identity, determining whether the user has input to thedistributed data store information consistent with the identity,retrieving first information on one or more relationships, existingoutside of the distributed data store, between the user and one or moreother users of the distributed data store, retrieving second informationon subsequent action taken on information regarding media content inputby the user to the distributed data store, wherein the subsequentactions include actions by other users confirming or challenging theinformation input by the user, and calculating a reliability metric forthe user based on whether the user has asserted an identity and inputinformation consistent with the identity, the first information on theone or more relationships between the user and the one or more otherusers, and the second information on the subsequent action.

In another embodiment, there is provided a method for maintaining adistributed data store storing information regarding a plurality ofmedia contents and a record of interactions with the plurality of mediacontents. The method comprises determining a reliability of informationstored by the distributed data store regarding a first media content.Calculating a score comprises evaluating a plurality of attributescharacterizing the media content that are stored by the distributed datastore, the plurality of attributes being a minimum permissiblecharacterization of the media content. Determining the reliabilityfurther comprises, for each of one or more records in the distributeddata store recording an interaction of a user with the media content,identifying the user and retrieving a trust score for the user andretrieving information on subsequent action taken on the interaction ofthe user with the media content, wherein the subsequent actions includeactions by other users confirming or challenging the information inputby the user. Determining the reliability further comprises calculating areliability metric for the media content based on the evaluation of theplurality of attributes characterizing the media content, the trustscore for the user for each of the one or more records, and theinformation on the subsequent action for each of the one or morerecords.

In a further embodiment, there is provided a method for maintaining arecord of identity of users of a distributed data store, the distributeddata store storing information regarding a plurality of media contentsand a record of interactions with the plurality of media contents. Themethod comprises, in response to receiving a notification from thedistributed data store that a first user of the distributed data storehas associated, in the distributed data store, a second user with afirst media content, prompting for a confirmation of or challenge to theassociation of the second user with the first media content. The methodfurther comprises, in response to receiving a challenge to theassociation, transmitting to the distributed data store a request torecord, in connection with the first media content, a challenge of theassociation, and, in response to receiving a confirmation of theassociation, transmitting to the distributed data store a request torecord, in connection with the first media content, an indication thatthe association has been confirmed.

In another embodiment, there is provided at least one non-transitorycomputer-readable storage medium having encoded thereon executableinstructions that, when executed by at least one processor, cause the atleast one processor to carry out the method of any one or anycombination of the foregoing methods.

In a further embodiment, there is provided an apparatus comprising atleast one processor and at least one storage medium having encodedthereon executable instructions that, when executed by the at least oneprocessor, cause the at least one processor to carry out the method ofany one or any combination of the foregoing methods.

The foregoing is a non-limiting summary of the invention, which isdefined by the attached claims.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings are not intended to be drawn to scale. In thedrawings, each identical or nearly identical component that isillustrated in various figures is represented by a like numeral. Forpurposes of clarity, not every component may be labeled in everydrawing. In the drawings:

FIG. 1 is an illustration of a computing environment in which someembodiments may operate, including a music workstation, a computingdevice associated with a performing rights organization (PRO), andcomputing devices adapted to play media stored in one or moredistributed data stores as disclosed herein;

FIG. 2 is a block diagram of some information regarding a media that maybe stored by a distributed data store in accordance with someembodiments;

FIG. 3 is a flowchart of an illustrative process for adding informationregarding a media to a distributed data store, which may be implementedin some embodiments;

FIG. 4 is a flowchart of an illustrative process for updating adistributed data store based on a user's response to being associatedwith media, which may be implemented in some embodiments;

FIG. 5 is a flowchart of an illustrative process for calculating a scoreindicating a reliability of a user in the system, which may beimplemented in some embodiments;

FIG. 6 is a flowchart of an illustrative process for calculating a scoreindicating a reliability of data regarding media, which may beimplemented in some embodiments;

FIG. 7 is a flowchart of an illustrative process for determining whetherand how to access a media, which may be implemented in some embodiments;and

FIG. 8 is a block diagram of a computing device with which someembodiments may operate.

DETAILED DESCRIPTION

Described herein are various embodiments of a system for trackinginterests in content using a distributed data store. By being“distributed,” there may be multiple different copies of the data storethat each hold a portion or all of the data of the data store, with thedifferent copies being continuously, periodically, or occasionallysynchronized to ensure that data held in one matches the data held inanother, but with no copy of the data store being treated as theofficial or canonical copy of the data store. The distributed data storemay track the interests regarding the content in particular ways,including through storing information identifying the content andidentifying interests in the content.

The distributed data store may be used to track interests in media, suchas to track ownership, management, or royalty interests in media likesongs, to provide a mechanism for “Digital Rights Expression” (DRE). DREdiffers from “Digital Rights Management” (DRM), including in that whileDRM may focus on techniques for precluding unauthorized access to mediasuch as through encrypting and then regulating decryption of the media.DRE may aid with identifying who participated in the creation of themedia and identifying who may authorize an access to the media andidentifying consequences of an access, like actions to be takenresponsive to an access and parameters of those actions, such as where anotification of a royalty-triggering event (e.g., public performance)should be sent. DRE may therefore not itself be used for regulating theaccess, or may not relate to any encryption or other restriction of themedia. In some cases, DRE may be used alongside DRM, for example, DREmay track interests in a song that is protected using a DRM technique.

To realize such Digital Rights Expression, the distributed data storemay be configured with a number of tools to help demonstrate reliabilityof data stored in the data store. Some conventional data stores may takesteps to ensure reliability of data, including by preventing anypotentially-unreliable data from being entered into the data store. Suchsteps make the data store or the operator of the data store the arbiterof reliability. The distributed data store of some embodiments may takea different approach, by instead storing in the data store informationthat may demonstrate to a user of the data store reliability of the datastore's information characterizing the media. The data store may thenenable users of the data store to leverage the indications ofreliability to make their own determinations of the reliability of thedata. Demonstrating reliability in this manner, rather than assumingresponsibility for ensuring and policing of reliability, may contributeto the “distributed” nature of the system and have certain advantages,as discussed below.

As an example of such techniques for demonstrating reliability, in someembodiments, the distributed data store may be configured with, andenforce, rules regarding a minimum set of information to be storedcharacterizing media, such as information identifying the media and/orinterests in it, before information about the media is permitted to beadded to the distributed data store. The minimum set of informationcharacterizing a song, for example, may include identifying informationfor the song, such as a title of the song, as well as informationidentifying an interest in the song, such as an artist (e.g., writer,musician, etc.) who owns rights in the songs and/or is to be paidroyalties for the song. Ensuring that information about media is onlystored in the data store when there is more than a minimum amount ofinformation may aid in preventing low-quality, and unreliable,information from being stored.

As another example of techniques to aid in demonstrating reliability, insome embodiments, the distributed data store may track, on amedia-by-media basis, interactions with the data store regarding eachmedia. Interactions with the data store regarding each media may includeadding or editing information characterizing the media, such as addingor editing information identifying interests in the media (e.g., anartist who contributed to the writing or performing of media, or recordlabel who owns rights in a song), or adding or editing informationregarding a consequence of an access. A consequence of an access mayinclude an action that is to be taken before, during, or after anaccess, like sending a notification that a royalty-triggering event(e.g., a public performance) has occurred. Storing information on suchan action may include, for example, storing information or parameters ofan action, such as identifying where such a notification should be sent.In tracking interactions with the data store, the distributed data storemay store identifying information for the party that was interactingwith the data store. The information regarding the interactions with thedata may be freely accessible in the data store, ensuring that users ofthe data store may be able to query the data and make their owndeterminations of reliability.

In some embodiments, the system including the distributed data store mayuse information on a media and/or on a set of interactions with the datastore to calculate a value indicative of a potential reliability of thedata regarding the media. For example, the system may evaluate how muchinformation has been stored characterizing the media (e.g., relative toa set of potential characterizing information, or relative to othermedia), and/or evaluate past interactions with the information regardingthe media (e.g., how much information has been edited following beingadded), and/or by evaluating the identity of users who have interactedwith the information regarding the media and the interactions of thoseusers with other media (e.g., how often information added by a user islater edited, which may indicate whether the user is generallyreliable). The distributed data store may make this value available,along with the information regarding a song, to aid users in determiningreliability of stored information.

As a further example of techniques to aid in demonstrating reliability,in some embodiments, if an interaction with the information regarding apiece of media results in a user being associated with a song, such asif a user is identified as an artist who contributed to a song, thedistributed data store may notify the user of the association. As partof the notification, the user may also be prompted to accept or rejectthe association. The user's response to the notification may beincorporated into an indication of reliability for the song, asdiscussed below.

The inventors have recognized and appreciated that the Digital RightsExpression (DRE) techniques described herein, including the distributednature of the technology described herein, may have certain advantages.

More specifically, the inventors have recognized and appreciated thatthere has been widespread difficulty in the music industry, stretchingback decades, in tracking contributions to a song and tracking who wouldbe owed royalties to a song. Particularly in cases when there aremultiple writers of a song, such as writers of different parts of thelyrics or writers of different melodies for different parts of a songs,but even in simple cases where a band includes a handful of musiciansthat all contributed to a performance of a song, the music industry hasbeen unable to consistently and dependably track who was involved in theproduction of a song. Because the industry cannot track who was involvedin the production of a song, the industry also cannot properlycompensate contributors. As a result, for decades, it has been commonfor contributors to a song to be under-compensated. Contributors mayhave contracted to receive a royalty that is some small fraction (e.g.,less than one percent) of the total revenues for a song, but because thecontributors are not reliably tracked, those funds cannot be deliveredor reliably delivered to the contributor.

Attempts have been made at mitigating this problem. Performance RightsOrganizations (PROs) were established decades ago to, in part, trackrights in music and ensure royalties are properly collected anddistributed. Such PROs would aggregate, at a single point, informationon who has contributed to a work and who is owed for performances of thework. Despite continued efforts of PROs, the problem remains widespread.Attempts have also been made at computer-implemented approaches totracking contributors to a song, such as the Global Database Repertoire(GDR), the International Music Joint Venture, and the InternationalMusic Registry. All were designed to address these difficulties intracking rights by allowing content creators to register their work inone centralized location, which would allow for those playing songs (andowing royalties) to easily identify the content creators and funnelpayments to the content creators. Similar to the conventional approachof a centralized organization like a PRO, all of the conventionalcomputer-implemented approaches included centralized databases, anddespite active interest from the industry, all were failures ataddressing the problem.

As a result of the difficulty in correctly channeling compensation tothose who contributed to a song, the music industry estimates thatannually, millions of dollars are lost or misallocated due to a lack ofinformation about rights ownership. In total, this under-compensationlikely amounts to billions of dollars. This substantially impacts theability of artists to receive income for their work, and has a sizeablenegative impact on the industry. Though widely acknowledged andstretching back decades, this problem persists due to difficulties thathave been encountered in all conventional approaches.

The inventors have recognized and appreciated that a distributedapproach to Digital Rights Expression (DRE) and to storing informationregarding interests in a song would be advantageous, and mitigatedifficulties encountered by prior approaches. The inventors recognizedand appreciated that all conventional approaches failed in large partbecause of inherent challenges in the kind of centralized authority thataccompanies having a centralized database. A centralized authority, suchas the operator of the database, takes responsibility for ensuring thecompleteness of the data and ensuring the accuracy of the data,including for resolving conflicts or disputes about the data. All thosewho have attempted to address this problem in the past viewed thisassumption of responsibility as necessary, to ensure that users couldtrust the stored data. The inventors recognized and appreciated,however, that assumption of responsibility for completeness and accuracy(in sum, reliability) is unnecessary. The inventors appreciated that fora data set as large and diverse as media rights information, centralizedresponsibility for reliability is untenable. The inventors insteadrecognized the advantages of a data store that explicitly does notassume responsibility for reliability and instead devolves thatresponsibility on users. In that context, though, the inventorsappreciated that some mechanism related to reliability would beadvantageous. The inventors recognized that an advantageous form of sucha mechanism would be one that demonstrates to a user the data, thesource of the data, and other indicators of reliability. These featureswould enable a user to make his or her own determination of reliability.The inventors further appreciated that, while a centralized data storecould offer such functionality, a particular form of a distributed datastore would be advantageous for reasons that will be appreciated fromthe discussion below.

Accordingly, some embodiments described herein administer rightsinformation using a distributed data store. The distributed data storemay store information about content and maintains a chronological log ofinteractions with that content. In some embodiments, the distributeddata store may be implemented as a blockchain. Embodiments are notlimited to operating with any particular implementation of blockchaintechnologies, and may operate with different examples of blockchainssuch as a Bitcoin-style blockchain, an Ethereum-style blockchain, ablockchain according to the approaches developed by Hyperledger, orother blockchain technologies.

In some embodiments, media for which information is stored in thedistributed data store may be associated with a particular filestructure. The file structure may, in some cases, include data for themedia (e.g., binary data for the audio, video, etc. of the media), whilein other cases the file structure may include a reference to a location(e.g., using a Uniform Resource Identifier (URI) or other identifier) atwhich the data can be accessed or from which the data may be obtained.The file structure may also include an identifier for the media that isunique with respect to the distributed data store, and may include anidentification of the distributed data store that stores the informationon the media. Some or all of the content of the distributed data storemay be included within the file structure, such as a set of informationcharacterizing the media and (in embodiments that include such a score)a score indicating the reliability of the information. When a mediaplayer uses a file having this file structure to play media, in somecases the media player may use the identifier for the media and theidentifier of the distributed data store to synchronize the informationincluded within the file with the distributed data store, which can helpensure the file is kept up-to-date. The media player may also use thefile to access the distributed data store and identify who is to be paidor notified of a performance of the song, and log that a notification orpayment is to be sent to the party or send such a notification orpayment to that party.

In some embodiments, more than one distributed data store, or more thanone blockchain, may be used to store information on interests in media.For example, in some embodiments, information characterizing a song maybe divided into information that is public and information that isnon-public or private. Public information may include information thatis publicly-viewable through the system, where the “public” may be anyregistered or unregistered user of the system. Publicly-viewableinformation may include information that may be used by others inidentifying a piece of media or using the media, such as informationregarding a name of a song or an artist who contributed to a song. Insome cases, all information about a media or about interests in a mediamay be public. In other cases, some information characterizing a mediamay be private. In some cases, for example, information on a rate of aroyalty due to a particular contributor to a song may be stored in adistributed data base, but that contributor or any other party may wishthat information not to be publicly-viewable. In some such cases,non-public information may not be stored in the same distributed datastore (e.g., the same blockchain) with public information, but mayinstead be stored in different distributed data store (e.g., a differentblockchain). In some such cases, both blockchains may be referenced inthe file for a media.

As discussed above, the inventors recognized and appreciated that priorapproaches to centralized storage of information on media and interestin the media failed, in part due to limitations on the need to ensurereliability of data. The inventors have recognized and appreciated theadvantages not only of a distributed system, but of a distributed systemthat does not take responsibility for ensuring reliability of data butinstead demonstrates the reliability of data in a manner that enablesusers of the system to determine whether information for a particularmedia is reliable and whether and how to use that information.

Media for which information is stored in the distributed data store maybe associated with a number of attributes: information identifying themedia (e.g., title), information identifying interest in the media(e.g., rights ownership information), a record of interactions with themedia content, as well as (in some cases) data for the actual mediaitself. These attributes may be stored in the distributed data store. Insome cases, the distributed data store may impose requirements onminimum data to be stored regarding a media before a record for themedia can be created in the distributed data store. For example, in thecase of a song, minimum permissible characterization may comprise thesong itself, information about the artist, the recording studio, and theproducer. The use of minimum permissible characterization may helpensure that every record on the distributed data store comprises aminimum amount of sufficient information to be accessed by a userinteracting with the media content on the distributed data store, andhelp ensure reliability of the data.

The distributed data store may also include a score or evaluation oftrust for media information in the distributed data store. In someembodiments, the score for the media content may be a reflection of thescore for individuals or parties connected to the media content as wellas the number of conflicts or inconsistencies within the record ofinteractions for the media content. The score for individuals or partiesconnected to the media content may be determined at least in part by thescores of other individuals or parties tied to that individual or partyas well as a point of reference for the user or party. For example, apoint of reference for a party may be any suitable identityverification, such as credit card information or a social media account.

The distributed data store may also allow users to associate other userswith a media content on the distributed data store. For example, if themedia content were a song, stored on the distributed data a first party,such as a representative for a recording label, could associate a secondparty, such as a musician for the song, with the media content on thedistributed data store. That interaction may additionally be stored onthe record of interactions for the media content on the distributed datastore. In some embodiments, that interaction may only be stored if thesecond party agrees to the connection. In some embodiments, thatinteraction may be stored if the second party does not interact with theconnection.

Examples are described below of particular environments in whichembodiments may operate, and particular techniques that may be used inembodiments to achieve different functionality. It should beappreciated, however, that embodiments are not limited to operating inaccordance with these examples, and that other implementations arepossible.

In addition, while for ease of description some of the examples arediscussed in connection with distributed data stores that are describedas “blockchains” and media is described as “songs,” it should beappreciated that embodiments are not so limited. Embodiments may operatewith other distributed data stores and may operate with media that maybe audio, visual (e.g., still image and/or video), or audiovisual.

FIG. 1 illustrates a computing environment 100 in which some embodimentsmay operate. The environment 100 includes a variety of devices that, asdiscussed below, may be operated by different users to perform functionsdescribed herein. The devices may communicate via network 110, which mayinclude one or more wired and/or wireless, local and/or wide-areanetworks, including the Internet.

The environment 100 may include a music workstation 102 or what may bealternatively referred to as a digital audio workstation. (For ease ofdescription, the embodiment of FIG. 1 will be described in connectionwith an example in which the media content is music, but it should beappreciated that embodiments are not limited in this respect.) The musicworkstation 102 may be used by one or more users, such as a sound orproduction engineer, to create or edit media content, such as a song.The music workstation 102 may be a part of a production booth or musicrecording station in some embodiments.

The music workstation 102 may be configured with and execute aningestion facility, which may obtain music data for a song, such asthrough a live recording of a studio session in which music is capturedthrough a microphone or other audio input device and received by themusic workstation. Additionally or alternatively, the ingestion facilitymay receive data for music from recordable media read by the musicworkstation (e.g., from a CD-ROM, minidisc, or other storage media), viaa network from another device, and/or otherwise input to the musicworkstation.

In some embodiments, music data received by the ingestion facility maybe used in creating a record for the song on a blockchain, as discussedin detail below. In other embodiments, music received by an ingestionfacility may be edited using music editing techniques, which may beimplemented by the ingestion facility or another facility (orcombination of facilities) executing on the music workstation. Theediting performed on media may include equalizing, sampling, cutting,mixing, finding, filtering, noise reduction, any suitable form of musicediting known in the art, as embodiments are not limited in thisrespect. In some cases in which music editing is performed, the editingmay be performed by the ingestion facility or triggered by the ingestionfacility, while in other cases the music editing may be performed by afacility prior to input of the music data to the ingestion facility, asembodiments are not limited in this respect.

The ingestion facility of the music workstation 102 may create a recordfor the song including data about the song. Data about a song mayinclude data identifying a song, such as a title of the song. Inaddition, as discussed above and in accordance with the Digital RightsExpression (DRE) of some embodiments, the data about a song may includedata regarding interests held by one or more people or entities in thesong, including information identifying the person/entity andinformation identifying the interest held in the song.

In some embodiments, as discussed above, a system including adistributed data store for tracking interests in media may not ensureaccuracy or completeness of data about a media, or otherwise centralizeresponsibility for reliability of data about the media. Rather, someembodiments may use one or more techniques to aid in encouragingcontribution of reliable data or aid in demonstrating the reliability ofthe data in the record. Some embodiments may leverage a set of minimumpermissible characterization for records associated with media in adistributed data store. As discussed above, the minimum permissiblecharacterization may aid in preventing low-quality unreliable recordsfrom being added to the distributed data store.

Accordingly, the ingestion facility of the music workstation 102 may, aspart of creating a record for the song on the blockchain 102A, createminimum permissible content associated with the song and the music datafor the song. The minimum permissible characterization may be requiredby the blockchain 102A to add the media content to the blockchain 102Aor create a record for the media content in the blockchain 102A. Forexample, in the case of a song, minimum permissible characterization mayinclude the song itself, information about the song, information aboutthe artist, and a unique identifier for the song in the data store. Thesong itself may be included in the record as music data (i.e., binarymusic data, in some cases encoded or compressed, and/or protected DRM)and/or a link to a suitable location from which the music data could beretrieved via a network. Information about the song may includeinformation identifying the song. This may include a title for the song,and/or other attributes such as an album for the song or a year the songwas released. Information regarding the artist may be for a performer orgroup of performers (e.g., band, symphony) for the song, such as a bandwho recorded the song, or for other artists affiliated with a song, suchas a composer, arranger, writer, or other artist. The unique identifiermay be an alphabetic, numeric, or alphanumeric value that may be used inthe distributed data store to identify the record. The minimumpermissible characterization may additionally or alternatively includeother information for a song, such as information identifying therecording studio associated with the music workstation 102, andinformation on actions to be taken responsive to a playback or otheraccess of a song such as a listing of the people or entities owedroyalties for use of the song, and contact information for each of thosepeople or entities. The content of the minimum permissiblecharacterization is not limited to any particular type or types ofinformation regarding a song. The use of minimum permissiblecharacterization may help ensure that every record on the distributeddata store includes sufficient information for the user to access anduse the data, when interacting with the media content on the distributeddata store, and help the user understand the reliability of the data inthe data store, as the minimum permissible characterization may includeenough information for the user to make a determination of reliability.

The blockchain 102A may be a distributed instance of distributed datastore. As should be appreciated from the foregoing, embodiments are notlimited to using any particular blockchain technology, nor areembodiments limited to using a distributed data store that implementsblockchain technology. The blockchain 102A may synchronize content withany or all of the other blockchain instances 104A and 108 through thecommunication network 110. There may be multiple different copies of thedata store that each hold a portion or all of the data of the datastore, with the different copies being continuously, periodically, oroccasionally synchronized to ensure that data held in one matches thedata held in another, but with no copy of the data store being treatedas the official or canonical copy of the data store.

A file wrapper local to the music workstation 102 may also be created,corresponding to a record of a media content on the blockchain 102A. Thefile wrapper may indicate a storage location of the record of the mediacontent on the blockchain through any suitable means, such as auniversal resource locator (URL), a hyperlink, a blockchain identifier,or a pointer, for example. The file wrapper may be shared or exchangedbetween users, so that a user receiving the file wrapper may play thesong or otherwise perform operations using the song. The file wrappermay include any or all of the content from the record of the mediacontent on the blockchain, including, for example, the minimumpermissible characterization. As another example, the file wrapper maycontain information on responsive actions like the royalty paymentinformation for the song, which may be used to identify to whomroyalties are due and how to pay the royalties. The file wrapper maysynchronize with the blockchain 102A, to receive updated informationregarding any or all of the associated record in the blockchain 102A.

In some embodiments, the music workstation 102 may (instead of being adigital audio workstation or other specialty device) be a computingdevice (e.g., laptop or desktop, personal computer, smart phones, orother devices) operated by a user such as an end consumer, which mayhave a library or other storage of media content. The user computer 102may add some or all of its media content to the blockchain 102A. In someembodiments, the user may not have direct rights to the media content,or may only have rights to the media content as a consumer, such as onlyhaving the rights to own a single copy of the song and to play a song asa private performance and not as a public performance, or similarrights. A user may operate the ingestion facility on the device to addthe media content to the blockchain 102A. In some embodiments, theingestion facility may only allow the user to upload information about asong without the music data, such as by instead providing a way for theuser to input a link to a source of the media data on, for example, theInternet. This may aid in preventing privacy, by preventing the userfrom uploading song data without authorization, but still allowing theuser to create a DRE record in the block domain.

The environment 100 may also include a PRO device 104. A PRO device maybe any device used by a Performance Rights Organization (PRO) to trackrights in music and/or ensure royalties are properly collected anddistributed. PROs conventionally aggregate, at a single point,information on who has contributed to a work and who is owed forperformances of the work. The PRO device 104 may have its own copy ofthe blockchain 104A, which may be synchronized to the blockchain 102A,in some embodiments. In some embodiments, the device 104 may execute aningestion facility like that described above to add a record for a songto a blockchain

In some embodiments, the blockchain 104A may be multiple blockchains.For example, the blockchain 104A may include a first blockchain,synchronized to the public blockchain 102A, and a second blockchain,containing data private to the PRO. For example, in some embodiments,information characterizing a song may be divided into information thatis public and information that is non-public or private. Some of thedistributed data stores may store only public information, only privateinformation, or both. A “private” distributed data store may be adistributed data store for which registration to gain access, and/oraccess, is limited to a group of potential users who meet one or morecriteria. Such criteria may vary between embodiments, and may includeusers having a particular employer, or a particular contractualrelationship (e.g., artists having a relationship with a particularPRO), having been invited by an existing user, or other criterion. A“public” distributed data store is distinguished from a private datastore by having a more expansive or an open pool of potential users.Some public distributed data stores may still require that usersregister to gain access, but the public distributed data stores may notimpose requirements on who may qualify as a user.

Various types of information may be classified as public, as embodimentsare not limited in this respect. Financial information may be one formof private data, in some embodiments, while related informationidentifying who is related to a song (and, in some cases, therefore whois owed money) may be public. For example, the public blockchain mayidentify, as an action that is to be taken following a playback, that aroyalty is owed to artists. The data on the blockchain may indicate thatthe PRO is coordinating royalty payments and is to be notified ofroyalties due. Accordingly, the PRO may receive a notification of apublic performance of a song. The PRO then may use the royaltyinformation or DRE information in the private blockchain to determinewho specifically is to be compensated and/or how much to compensate eachperson or group associated with the song. The PRO may want toparticipate in the blockchain system and receive notifications via thesystem, but may not want to make the business data (e.g., royaltyinformation) available to the public.

The PRO may also use the PRO device 104 to track, monitor, or manageroyalty payments. The PRO may use information stored in the blockchain104A to determine relative amounts and/or distribution methods forroyalties owed to various users associated with a song when the song isplayed commercially, for example.

The PRO device 104 may also be used to receive and/or sendnotifications, as will be described in further detail below. Forexample, the PRO device 104 may receive a notification through the PROdevice 104 that the PRO has been “tagged” in a media content or that anartist or other user for whom the PRO manages rights her been tagged.The PRO device 104 may receive a notification because the PRO or anotherparty supplied an identifier for the PRO device 104 or for a useraccount affiliated with the PRO device 104 (e.g., an email address, userID, or other account identifier to the blockchain and indicated thatnotifications for the PRO or artists should be sent to the device 104 oraccount. A tag may associate the PRO or an artist with the record of themedia content in the blockchain 104A such as by identifying that the PROhas an interest in the media content, such as by identifying aparticular role the PRO or artist supposedly played with the mediacontent. The tag may identify, for example, that an artist wrote orperformed the song, or that the PRO is to be notified of aroyalty-triggering event for the song. The PRO may also use the PROdevice 104 to tag another user in a record for a media content in theblockchain 104A. For example, the PRO may tag an artist whose rights aremanaged by the PRO in a record for a media content that the artist isassociated with. The tag may associate the artist with the media contentin the blockchain 104A.

The environment 100 may also include devices 106A, 106B, and 106C(including or collectively referred to herein as devices 106),configured to consume media content and/or interact with the blockchain108. The devices 106 may receive a file that includes content or theblockchain 108 for a song. For example, any of the devices 106 mayreceive a file corresponding to a record for a media content on theblockchain 108 which, as discussed above, may include the minimumpermissible characterization or other attributes of the song. The filemay include only the media content, or any parts of the record for themedia content. The device 106 may access the file, including the contentfrom the blockchain with the DRE material, to play back or otherwiseaccess the song. As discussed above, the file may include the music dataor may include an identifier (e.g., URI, URL) for a source of the musicdata, in addition to the DRE material. The device 106 may therefore playthe song or otherwise access the song (e.g., for editing or otherpurposes) using the file. By accessing the song using the DRE file, thedevice 106 may be able to, or required to by smart contracts or otheraccess control mechanisms in the file, perform one or more actionrelated to the song. For example, the record for the song on theblockchain may specify that each playback of the song be logged in theblockchain, or that a notification of a royalty-triggering event be sentto a designated entity, before playback is performed. These controls maybe laid out in the file. In some cases, the music data (either includedin the file, or available from a source) may then also be protected witha DRM technique, but embodiments are not limited in this respect.

The devices 106 may interact with the blockchain 108 to verify theaccuracy of the file received from the blockchain 108. For example, thedevice may use a blockchain identifier associated with the file toidentify the record for the media content within the blockchain 108, andmay verify the rights of the device 106 relative to the media content inthe instance of a royalty-triggering event, or otherwise verify content.

The devices 106 may also interact with the blockchain 108 by addinginformation to the blockchain 108. The devices 106 may execute aningestion facility like that described above to add the record to ablockchain for media. For example, any of the devices 106 could, afterreceiving the file described above, update a ledger within theblockchain corresponding to the media content to log that the device hasaccessed the media content. As another example, any of the devices 106could tag a user associated with the media content in the blockchain.

In the case where the media content is a song, the devices 106 mayperform a playback operation. The device 106 may play the song directly,once the song is obtained by the device 106. In some embodiments, thedevice 106 may verify that the user of the device 106 has the right toplay the song by determining its rights through the blockchain 106, asdescribed in greater detail herein. In some embodiments, the device 106may play the song through a playback facility. The playback facility mayhandle the rights verification, as well as any of royalty payments, PROinteractions (such as notifying the PRO of playback), storage of thesong, editing of blockchain records, tagging notification, and/orplayback of the song. In some embodiments, the playback facility may besimilar to music streaming services, such as Pandora® or Spotify® andthe device 106 may be a server (including one or more virtual machines,a distributed set of coordinated servers, or other serverimplementation). In some embodiments, the playback facility may be anapplication local to the device 106 that performs any of thecapabilities described above.

FIG. 2 is a block diagram of some information regarding a media that maybe stored by a distributed data store 212 in accordance with someembodiments. The distributed data store 212 may be a blockchain or otherdistributed storage, as described above, and may contain information 200regarding media content. The information 200 may comprise a link 202 tomedia data, attributes 204 characterizing the media, a transactionrecord 208, and a reliability score 210. The link 202 to media data maycomprise any suitable content for granting a user access to the mediadata. For example, in some embodiments the link 202 may be an address oridentifier like a URI or URL, a pointer to a location of the media datain memory or a web address for a remote server or remote data store. Insome embodiments, in addition to or as an alternative to storing a linkfor a source of the music data, the record might include the music data,such as by storing a digital representation of a waveform for the musicdata. In cases in which the music data is stored, the music data may insome cases be compressed or encrypted using suitable techniques forencoding to limit storage size or DRM techniques for controllingdistribution or access. As should be appreciated from the foregoing,though, embodiments are not limited in this respect. The attributes 204characterizing the media may include the attributes identified in theminimum permissible characterization 206, and any other attributescharacterizing the media. The minimum permissible characterization 206may be information characterizing a song, for example, may includeidentifying information for the song, such as a title of the song, aswell as information identifying an interest in the song, such as anartist (e.g., writer, musician, etc.) who owns rights in the songsand/or is to be paid royalties for the song. In some embodiments, thedistributed data store 212 may require that the attributes 204 for anyor all media content stored on the distributed data store 212 containminimum permissible characterization 206. In some embodiments, othercomponents of the system 100 may enforce the requirement that theattributes 204 for any or all media content stored on the distributeddata store 212 contain minimum permissible characterization 206. Forexample, ingestion facilities that create records in the distributeddata store 212 may be configured not to create a record until at leastinformation for the minimum permissible characterization is available.The attributes 204 characterizing the media may further compriseinformation characterizing the media beyond the minimum permissiblecontent 206. For example, the attributes 204 characterizing the mediamay contain information about people involved with the media who are notowed royalties, which could include a variety of people like recordingengineers or writers who were paid upfront and are not owed a royaltybut are given attribution for their work on the media, or about furtherpeople involved with the media who are owed royalties but are notrequired in the minimum permissible content which could include managersand service providers who might get a “cut” in the song but may not bepresent in all scenarios and are thus not required to be listed.

The transaction record 208 may comprise a record of any or allinteractions with the information 200. Such interactions may compriseadding information, removing information, updating information, ormerging of records. The information stored in the transaction record mayinclude information identifying the party executing the interaction andinformation describing the interaction, for example. The informationidentifying the party may include information identifying a personand/or a user account with the distributed data store of a person.Additionally or alternatively, an entity (e.g., a PRO, recording label,music streaming service) may be a party or may be affiliated with (e.g.,the employer of) a party, and may be identified in the transactionrecord. The information identifying a user account may be a uniqueidentifier for the user account assigned to the user account by the datastore, a user name, or other information. Information identifying aperson may include a name, address, email address, social media account,or other information that may be used to uniquely identify the person.The information describing the interaction may include informationidentifying what information was read out of or written to a record formedia content, in the case an interaction was with the record, or whatwas done (e.g., playback, editing) with music data if the interactionwas with the music data (or other media data). The informationdescribing the interaction, including identifying the party anddescribing the interaction, may aid in demonstrating reliability of amedia content record, as this information may be consulted to determinean origin of each piece of information in a record and to determine howthe record has changed over time. In some embodiments, a time stampidentifying a time or an interaction, or a time at which the data storereceived a notification of the interaction. In some embodiments, aunique identifier may be generated for each interaction and stored inthe transaction record. In some embodiments, an interaction may includetwo or more parties. In such an instance, the transaction record mayrecord the identities of the included parties, and optionally alsorecord their roles within the transaction.

The reliability score 210 may be one or more values corresponding to anindication of the reliability of the information 200 regarding the mediacontent. The reliability score 210 may be determined from an analysis ofthe record for the media content, including according to analysesdescribed herein. For example, the reliability score 210 may be based onthe number of attributes stored in the attributes 204 characterizing themedia. In some embodiments, the reliability score 210 may be based onthe reliability scores of individual user identified in connection withinteractions in the transaction record 208. In some embodiments, thereliability score 210 may be based on the number of conflicting recordsstored in the transaction 208. It should be appreciated that these aregiven merely as examples, and in some embodiments the reliability score210 may be based on any combination of, or none of, those factors.

In some embodiments, a file wrapper may be associated with a record onthe blockchain. The file wrapper may include any or all of theinformation regarding media content 200, and may be used as a localversion of the information for a user of the blockchain such as the filewrapper described briefly above in connection with FIG. 1. For example,a user desiring to play a song stored on the blockchain may download thefile wrapper from the blockchain. In such an example, the file wrappermay contain the link to the media data 200 as well as any of theattributes characterizing the media 204, such as the title and artist ofthe song, or cover art for the song, so that the user may play back thesong. Additionally, the file wrapper may contain any DRE informationassociated with the media data, to aid the user's playback device orsystem in determining rights allocation. The file wrapper's link to themedia data may be any indication of a storage location of the media dataor song, such as a pointer to an address in memory, a URL, a blockchainaddress, or the media data itself. The file wrapper may also contain anyor all of the transaction record 208 and/or the reliability score 210,which the user may in some embodiments use to verify the reliability ofthe information within the file wrapper. In some embodiments, a user maydownload a file wrapper from the blockchain, corresponding to one ormore records in the blockchain. In some embodiments, a user may create afile wrapper for a media content and upload it to the blockchain tocreate a new record on the blockchain or modify an existing record onthe blockchain, as will be explained in further detail below.Additionally, in some embodiments a file wrapper may synchronize itsinformation with the blockchain, so that the information within the filewrapper may be kept up to date with any changes in the correspondingrecord on the blockchain. It should be appreciated that while thediscussion above is in the single blockchain, the file wrapper maycontain information from multiple blockchains, such as a privateblockchain and a public blockchain as described above.

In some embodiments, the process may be performed by a cloud gateway. Anuploading system that may be used in some embodiments may be a cloudgateway that acts as interface between the user and the blockchain. Thecloud gateway may receive input from a user and, responsive to thatinput, perform updates, to the blockchain by writing input data to theblockchain or read data from the blockchain. The cloud gateway maytranslate actions from, or requests by, the user into operations on theblockchain. For example, the user uploading media content to the cloudgateway may be translated by the cloud gateway into any of the stepsdetailed below. By having a cloud gateway between the user and theblockchain, the user may interact with the cloud gateway in a consistentmanner regardless of the nature of the blockchain behind the gateway.Such a gateway allows for interaction with multiple blockchains ormultiple types of blockchains. For example, the user could upload newmusic content to the cloud gateway, and the gateway may trigger theaddition of a new record to the blockchain regardless of whether theblockchain is implemented through Ethereum, Bitcoin, or any othersystem. Additionally, the cloud gateway may act as a batch importsystem. For example, if a PRO wanted to add an entire music library to ablockchain, the cloud gateway may pull the information from the musiclibrary, as described below, and create corresponding new records on theblockchain. The cloud gateway may also send and receive notificationscaused by tagging and creating claims, as will be described in furtherdetail below. For example, if a new song that is uploaded to the cloudgateway by a PRO has an artist tagged by the PRO, the cloud gateway mayissue a notification to the artist alerting them of the tag.

FIG. 3 is a flowchart of an illustrative method 300 for addinginformation regarding a media to a distributed data store. The method300 may be performed by an ingestion facility executing on a device suchas the music workstation or end user device of FIG. 1, for example. Oncea new song is recorded or otherwise created (e.g., through editing, oronce song data is otherwise received as input, the song and itsassociated information (for example the title, artist, DRE, or any otherinformation in the minimum permissible content) may be added to thedistributed data store from the music workstation. In another example,the method 300 may be performed by an ingestion facility on the PROdevice of FIG. 1 when the PRO seeks to create a record on thedistributed data store for a song or other media content for whichrights are managed by the PRO.

The method 300 may begin at step 302. In step 302, the system mayreceive at least one media content to be added to the blockchain. Themedia content may comprise a media file, such as a song or image, and/orinformation about the media file, such as information characterizing asong, for example, may include identifying information for the song,such as a title of the song, as well as information identifying aninterest in the song, such as an artist.

In step 304, the system may extract information from the at least onemedia content. In some embodiments, the system may attempt to extractinformation relating to the minimum permissible content for a record onthe blockchain. For example, the system may attempt to extractinformation relating to the title of the song, the artist of the song,the record label for the song, and any other parameters in the minimumpermissible characterization. The system may also extract informationnot required by the minimum permissible content, or may extract otherinformation provided in the media content. Extracting information mayinclude searching the file for a song, or a music library, orinformation maintained by a music workstation for metadata about thesong. Depending on the nature of the source of metadata from which thedata is being extracted, the extraction may take different forms. Forexample, if the information is being extracted from a file for the song,such as a conventional MP3 file, the extraction may involve extractingthe information from data fields within the file that include songattribute information, such as IDS3 fields for an MP3 file. If themetadata source is a library, a catalog file for the library or otherlisting of song attribute information may be queried. In someembodiments, a data service, such as one hosted on the web, may be usedto extract song attribute information. For example, the song data may beused to generate a “fingerprint” for the song using known techniques, orsome attribute information may be extracted, and the fingerprint orattributes may be used to query a service.

In step 306, the system may verify that the data extracted satisfies theminimum permissible characterization; that is, every field in theminimum permissible characterization may be filled with correspondinginformation. If the minimum data is received, the system may proceed tostep 310. In step 310, the system may add information on the mediacontent to the distributed data store. Adding information on the mediacontent to the distributed data store may include, creating a record forthe media content on the distributed data store. The record that iscreated may include the song attributes of the minimum permissiblecharacterization, and may additionally include a unique identifier forthe media content. The unique identifier may be generated in anysuitable manner, as embodiments are not limited in this respect. Forexample, the ingestion facility may generate a unique identifier (whichmay be a pseudo-unique identifier) using a process identified andconfigured for the blockchain, or may be generated upon request by aservice associated with the blockchain using such a process and suppliedto the ingestion facility. In some embodiments, such a unique identifiermay be one element of a minimum permissible characterization for ablockchain.

In some embodiments, as discussed above, a record may include—and aminimum permissible characterization may include—music data for the songor an identifier (e.g., an address such as URI or URL) for a source ofthe music data. The source of the music data may be a music service suchas Spotify®, SoundCloud®, Apple Music®, or other service, and theidentifier may be for a manner in which the song data may be retrieved,such as a web location at which the data is stored and accessible.

In some embodiments, a record may also include a transaction record forthe song, which as discussed above may include a history of interactionswith the record. In embodiments that include such a transaction record,and in which a transaction record is created when a song record iscreated, the transaction record may store information describing thecreation of the song record, such as identifying a person or entity whocreated the record and a time at which the record was created. In someembodiments, the transaction record may be created when a firsttransaction occurs involving the record after the creation of therecord.

In some embodiments, the record may also include a reliability score forthe record. Examples of techniques for generating a reliability scoreare discussed below such a technique may be used to create a score andadd it to the record, when the record is created.

If it is determined in block 306 that the minimum data is not received,the system may proceed to step 308. In step 308, the system may requestany additional information needed for the minimum permissiblecharacterization. For example, if a user attempts to upload a song, butomits the title of the song and the minimum permissible characterizationrequires a title for the song, the system may prompt the user to providea title for the song. The request may take any suitable form, such as aprompt to the user, an electronic message sent to the user alerting themthat the record is incomplete, or a request through an API for moreinformation, for example. In some embodiments, the system may notprovide a further request for additional information, and may simplyterminate the upload of information. In some embodiments, the system mayrequest additional information needed for the minimum permissiblecontent if information was received but was determined to not besufficient for the minimum permissible content. For example, if theminimum permissible content requires a publisher for the song, and thesystem extracts or receives information about the publisher but does notrecognize the name of the publisher, by comparing it to a list of knownpublishers, for example, the system may request additional informationabout the publisher.

When a record is created in this manner, in many cases one user mayidentify in a record that another user is associated with a song (orother media), such as when an artist is identified as a performer for asong.

This association may be referred to herein as “tagging.” In someembodiments, when a first party “tags” a second party in a record thesecond party may then receive a notification of the tag and be promptedto respond. The second party may accept, decline, or ignore the tag.Such a system of tagging and notifications may be helpful in someembodiments, as part of helping increase reliability or helping todemonstrate reliability of data in the records. As discussed above, anoperator of the distributed data store may not assume responsibility foraccuracy or completeness of the records, but may instead devolve thatresponsibility to users. A system of notifications may help withreliability, by permitting any user to tag any other user but alsoprompting that user to approve or reject the tag. This may aid inincreasing reliability of originally-input data, to help suppress falsedata input to the system. It is possible a user may also falsely, orincorrectly, accept or reject a tag. In some embodiments, this secondsource of potentially-incorrect information is addressed with atransaction record for each song record (or record for other media). Asdiscussed above, a second party may accept, decline/reject, or ignore atag. Regardless of the option taken, the decision made by the artist maybe recorded in to the transaction record of the media content on theblockchain, along with the original tag. Since, as described above, theblockchain does not assume responsibility for the accuracy of the storedinformation, maintaining a record of each tag (the identity of theissuing party, the identity of the responding party, and the response tothe tag) may aid in demonstrating to a user, or enable a user to reachan independent conclusion of, the reliability of the information storedon the blockchain. When all tags for a song have been accepted, the songdata may appear to be more reliable. When the transaction record shows alot of rejected tags, the data may appear less reliable. The number ofdeclined tags may, as discussed below, influence a trust score for arecord on the blockchain, and the number of tags issued by a user thatare then declined or even ignored may influence the trust score for thatuser, as will be described in greater detail below.

In some embodiments, a second party that receives a tag for a record mayaccept the tag but record in the blockchain an identity of a third partythat is to take responsibility for future interactions with theblockchain regarding the second party's role as specified in the record.For example, an artist may be tagged in a song record by a studioengineer. The artist may accept the tag as correct, and the blockchainmay record the acceptance of the tag as described below. The artist mayupdate the blockchain to record (in connection with a profile of theartist on the blockchain, or in connection with a song record in whichthe artist was tagged) that a manager, PRO, producer or other party isto be contacted regarding the artist's role in the music. Futurecontacts may include identifications of royalty amounts due to theartist in connection with performances or sales of the song, orquestions about whether the song may be sampled, covered, or otherwiseused in producing another song. To identify a third party as the contactpoint for such future contacts, the second party may add to theblockchain information identifying the third party and/or identifying amanner in which to contact the third party, examples of whichinformation are discussed elsewhere herein.

Method 400 is an example of a process for notifying a party in responseto a tag, and prompting the party to respond. The process may beimplemented by a facility related to the blockchain, such as by aservice executing on a server hosting at least a part of the blockchainor on a device (e.g., device 103, 104, 106 of FIG. 1) that has access toor hosts at least a part of the blockchain. The method 400 may beginwith step 402. In step 402, an attribute update facility may receive anindication of a first party associating a second party with a mediacontent. The indication may be received by the attribute update facilitydirect from the ingestion facility that initially created the recordthat includes the tag, which may be execution on the same device as theattribute update facility (or even another component of the sameapplication as the attribute update facility). The indication may alsobe received in the form of receiving the tag initially, such as in acase that the attribute update facility includes functionality to makediscrete changes to a record for a media content on the blockchain, suchas by adding an attribute not previously included in the record, orcharging a value for an attribute, or other charge. The indication mayalso be received, in some embodiments, through a blockchainfunctionality, such as a synchronization process that sends a chargemade to a record from the device that made the charge to other devices.That charge may include a tag, and may be an indication of a tag. Instep 404, the attribute update facility may issue a notification of thetag to the second party. In some embodiments, the system may obtain amethod of or means for contacting the second party by consulting theblockchain. For example, the blockchain may store an email address foran artist associated with a song, and the system may contact the artistthrough the email address if another user attempts to modify or deletethe artist's tag on the song. In some embodiments, the system may querya profile of the second party, on the blockchain or within the PRO, forexample, to determine contact information for the second party. In otherembodiments, if the second party is not yet a user of the system, thesystem may prompt the first party for a means of contacting the secondparty. If the first party provides the means for contacting the secondparty, a corresponding note may be made in the transaction recordindicating that the first party provided the contact information for thesecond party. In some cases, notifying the second party may includenotifying a representative of the second party, such as a PRO ormanager, that the second party has designated (e.g., with a record inthe database) is to receive and process notifications for the secondparty.

The notification may take any suitable form of notification. Forexample, the system may send an e-mail or a short message service (SMS)message to the second party, alerting them of the association with themedia content. The system may also or alternatively alert the secondparty through a social media account that the second party has linked tothe system. The notification may trigger a prompt to the second party toaccept or decline the association, or may provide instructions for thesecond party to respond to the notification. The notification may, forexample, include a URL for a web page for the second party to access,which may include the prompt to the second party. The notification mayadditionally or alternatively be directed to and received by a programthat is operated by the second party to interact with the blockchain,such as a music player that reads DRE information as part of playingmusic. Such a program may be configured to, in response to thenotification, prompt the second party to accept or reject the tag, andthe second party may accept or reject, or ignore the prompt.

In step 406, the system may obtain an indication of the second party'sresponse to the notification. If the second party declines theassociation, the system may proceed to step 408. In step 408, the systemmay record a conflict in the transaction record for the media content.Recording a conflict may comprise creating an entry in the transactionrecord including an identity of the first party, an identity of thesecond party, and record of the declination of the association. In someembodiments, recording the conflict may comprise issuing a request orupdate to the blockchain indicating that the second party declined theassociation. Recording the conflict—that is, a conflict between theoriginal tag and the decline (where a decline at least indicates thatthe original tag may have been incorrect)—rather than deleting theoriginal tag may stem from the approach to reliability in someembodiments. Because the operator of the blockchain is not centralizingresponsibility for the reliability of the data, it may be valuable forthe blockchain not to accept either the initial tag or the rejection ofthe tag as “true.” Instead, the blockchain may store both the tag andthe rejection, and make both publicly visible. A query for a “current”status of the record may not include the tag, following the rejection,but the transaction record may list both the tag and the rejection.

If the second party accepts the association, the system may proceed tostep 410. In step 410, the system may update the media content. Updatingthe media content may comprise recording the identity of the secondparty and the information associated with them (e.g., recording the nameof the artist and labeling them as the artist for the media content). Insome embodiments, the identity of the first party and the informationassociated with them may also be recorded and associated with the tag ofthe second party. In some embodiments, updating the media content maycomprise issuing a request or update to the blockchain representing thesecond party's acceptance of the association. In some embodiments, thesystem may further record in the transaction record that the secondparty accepted the association from the first party.

If the system receives no indication that the second party has eitheraccepted or declined the association after a certain amount of time (forexample 1 day, or 1 week, or 1 month) in step 412, the system mayproceed to steps 414 and 416. The amount of time before proceeding maybe set by the first party, for the tag or tags entered by the firstparty, may be set by the second party for tags listing the second partyor for users managed by the second party, may be a fixed constant in theblockchain set by an administrator, or set in any other way. The systemmay record the time interval used in the transaction record on theblockchain or within the media content on the blockchain, for example.Alternatively, the time interval may be sent to the second party alongwith the notification. The first party's or second party's system, suchas an application (e.g., the attribute update facility) designed tointerface with the blockchain, or another component of the system suchas a server managing a part of the blockchain, may automatically alertthe attribute update facility after the time interval if no responsefrom the second party has been recorded. In step 414, the media contentmay be updated, as described in step 410. In step 416, a conflict may berecorded as in step 408, except that the entry created in thetransaction record may reflect that no response was received from thesecond party rather than that the tag was rejected.

In some embodiments, the conflict may be recorded or the media contentmay not be updated, as set by an administrator.

In some embodiments, a tagging hierarchy may be used. The hierarchy mayestablish requirements necessary for a first party to be able to tag asecond party. In some embodiments, the requirements may restrict theability of the first party to tag a second party that does not fallwithin the first party's portion of the hierarchy. The hierarchy mayrelate to roles within the music industry, such as job roles within theindustry, or to a particular corporation or record label and artistssigned to test label or employees of the corporation. For example, ahierarchy may be established that allows a second party with a secondportion of the rights to a set of media content to only be tagged by afirst party with a first, larger portion of the rights to the mediacontent. For example, a record label may tag a recording engineer, but arecording engineer may not tag a record label. As another example, ahierarchy may be established that allows a second party to be tagged bya first party only if the second party falls below the first party in acorporate structure (e.g., a record label executive may tag a producer,but a producer may not tag a record label executive).

In some embodiments, the tagging hierarchy may vary depending on a trustscore of a user within the blockchain. In some embodiments, the tagginghierarchy may vary depending on the trust score of the media content.The tagging hierarchy may aid in storing reliable information on theblockchain, as it may prevent unwanted parties or malicious parties frommaking incorrect tags or attempting to ‘steal’ credit for content bytagging themselves in it. Since the blockchain cannot independentlyverify information stored within it, as would be expected of acentralized rights authority, the tagging hierarchy may demonstrate thereliability of the stored information.

In some embodiments, a token system may be used to regulate tagging. Atoken may correspond to a user's ability to make a modification to theblockchain. Each interaction with the blockchain may “spend” a token.For example, uploading a new media content to the blockchain may requirea token, or modifying an existing media content on the blockchain mayrequire a token. Users may be granted a fixed number of tokens whentheir account is first created. In some embodiments, a user may “spend”a token when making a claim, such as tagging a party in a media contentor uploading a new media content. When a user runs out of tokens, theuser may be precluded from making more claims, which may have an effectof suppressing low quality data. However, in some such embodiments, highquality data may still be accepted. In some such embodiments, a user mayrecover spent tokens when a claim made by the user is verified byanother user or party such as the tagged party. The user may also earntokens by confirming or rejecting a tag entered by another user. Thetoken system may aid in combatting spam on the blockchain, or peopleattempting to upload large media libraries and improperly taggingthemselves in the media content. It should be appreciated that not allclaims may require a token in some embodiments, and the number of tokensgiven to a user may vary by user or by embodiment. It should also beappreciated that, in some embodiments, users may not be able to recovertokens. Similarly to the tagging hierarchy, the token system maydemonstrate the reliability of the information stored on the blockchain.The token system may deter unwanted or malicious users from makingneedless incorrect tags, or attempting to tag themselves or anotherparty in a disproportionate number of records. A centralized rightsauthority would be required to take responsibility for ensuring thecompleteness of the data and ensuring the accuracy of the data, but inthe distributed data store the token store may be paired with any of thefeatures described above to help maintain the reliability of the dataalong with transparency of the source of the data.

In some embodiments, as part of demonstrating reliability of data in theblockchain, the blockchain may not only expose underlying data and ahistory of interactions as discussed above, but may also calculate ametric that is indicative of and a summary of that data. The metric mayindicate a reliability or trustworthiness of the data. In someembodiments, two such metrics may be calculated: a trust score for auser and a trust score for a media content.

FIG. 5 is a flowchart of an illustrative method 500 for calculating atrust score indicating a reliability of a user in the system. The method500 may be performed by a score facility executing on a cloud gatewaybetween a user and the blockchain or by another device interacting withthe blockchain. For example, the PRO device shown in FIG. 1 may be usedto determine the score for users associated with a blockchain recordthat is of interest to the PRO. The PRO may use the scores to determinewhether or not to accept a tag by another party, for example, or toresolve a conflict in the transaction history of a blockchain recordassociated with the PRO. In another example, the blockchain may generatea score for each user tagged in a media content in the blockchain oreach user logged in a transaction record for a media content on theblockchain, to provide additional transparency to another partyexamining or working with the media content on the blockchain. Inanother example, the cloud gateway used by a party to add information toor modify information on the blockchain may assign a score to that useras well as other parties that the user interacts with through tagging.

The method 500 may begin with the facility obtaining a point ofreference of a user in step 502. The point of reference of a user may beany suitable information establishing the identity of the user in amanner that may verify a user's claim to an identity outside theblockchain, in the real world. For example, the point of reference maybe a social media account of the user, credit card information for theuser, or information verifying the employment of a user. Suchinformation may be input by the user, and may be used by the system toconfirm an identity claimed by a user. For example, an identity (e.g., aname, an employer) associated with a social media account or a financialaccount may be compared to an identity (e.g., a name, an employer)asserted by a user, to determine whether there is a match. Accordingly,in some embodiments, a social media profile, a financial account, and/oran employer email address may be used to confirm an identity asserted bya particular user. In some embodiments, the point of reference may be atag of the user by a second, verified user. In some embodiments,multiple points of reference may be obtained for a user. The system mayobtain the point of reference through the user's account within thesystem, or through a record of the user in the blockchain, for example.A PRO may use an employee's company email address as a point ofreference when generating a score for the employee, for example, throughthe PRO's internal company logs. In another example, a cloud gateway mayretrieve social media information used by a user of the cloud gateway tocreate an account within the cloud gateway. In some embodiments, as partof obtaining the point of reference the facility may validate the pointof reference. For example, the facility may validate credit cardinformation or validate a corporate email address, or perform othersuitable validation.

In step 504, the system may obtain information about relationships ofthe user to other users of the blockchain. Relationships between usersmay comprise any tags between the users, social media links if the pointof reference includes a social media account, or any other tie betweenusers that the system may access. In some embodiments, the relationshipmay be an employment relationship, for example the system may obtaininformation that the user, for example a sound engineer, works for asecond user, for example a recording studio. In some embodiments, therelationship information may be obtained from an external third partyauthentication service. For example, a social network external to thedistributed data store could provide a verification of a connectionbetween two users.

The system may collect this information on links to other users because,in some embodiments, a user with more professional or even socialrelationships to other users may be more trusted than one with fewer orno connections.

In step 506, the system may obtain information about interactions of theuser with one or more media content and subsequent responses to thoseinteractions. For example, the system may evaluate the number of tags auser has made, and further evaluate how many of those tags were acceptedby the tagged party. In some embodiments, the system may evaluate howmuch additional information the user has provided for a media content,and/or evaluate if any of that additional information has beensubsequently modified by another user. This information may be useful incalculating the reliability score because a user whose contributions areoften overruled may be less trustworthy than one whose contributions areapproved by other users.

In step 508, the system may generate a trust score for the user. Thetrust score may be a value representing the trustworthiness of the userwithin the system, and may be updated or modified over time. The systemmay utilize any of the above listed information to generate the trustscore, by weighting the information. For example, a number ofconnections may be assigned one weight and numbers of claims accepted orrejected may be given other weights.

FIG. 6 is a flowchart of an illustrative method 600 for calculating ascore indicating a reliability of data regarding a media content. Themethod 600 may be performed by a score facility executing on theblockchain, by a cloud gateway between a user and the blockchain, or byanother device interacting with the blockchain. For example, the PROdevice shown in FIG. 1 may be used to determine the score for ablockchain record that is of interest to the PRO. The PRO may use thescore to determine whether or not to use the DRE information or royaltyinformation associated with the record when determining royaltypayments. In another example, the blockchain may generate a score foreach blockchain record, to provide additional transparency to anotherparty examining or working with the media content on the blockchain. Inanother example, the cloud gateway used by a party to add information toor modify information on the blockchain may assign a score to eachrecord added to the blockchain by analyzing the information associatedwith the media content, as will be explained in further detail below.The method 600 may begin with the facility evaluating the completenessof the attribute data in step 602. In some embodiments, the system mayevaluate the completeness of the minimum permissible content, byensuring that every requirement in the minimum permissible content issatisfied, and/or by evaluating how much additional attributes outsideof the minimum permissible content are stored in the attributescharacterizing the media. For example, in the case of creating a scorefor the song when the song is first uploaded to the blockchain, theingestion engine or cloud gateway may evaluate how much informationbeyond the minimum permissible content is provided, or how complete theminimum permissible content is, when creating the song score. In anotherexample, the blockchain may evaluate a record on the blockchain bydetermining how much attribute data is provided beyond just the minimumpermissible content in the record.

In step 604, the system may identify one or more users who contributedinformation to the attributes characterizing the media, through thetransaction record of the media content. The system may further obtainthe trust scores of the one or more users. In one example, theblockchain may use the transaction record to identify all the partiesassociated with a blockchain record for a media content, as well as anytags associated with the media content. In another example, an ingestionengine or cloud gateway may use any tags associated with the imported oruploaded media content to identify all the parties associated with themedia content, as well as the identity of the person or party performingthe uploading. The trust scores for the one or more users may becalculated by the system as described above, may be pulled from adatabase of system users, or may be retrieved from information stored onthe blockchain about the users, for example.

In step 606, the system may check if there are any conflicts recorded inthe transaction record for the media content. If there are, the systemmay proceed to step 608. In step 608, the system may evaluate the numberof conflicts recorded in the transaction record and/or check if any orall of the conflicts are indicated as having been resolved.

In step 610, the system may generate a trust score for the mediacontent. The trust score may be a value representing the trustworthinessof the information stored on the blockchain regarding the media content,and may be updated or modified over time. The system may utilize any ofthe above listed information to generate the trust score, with anysuitable weighting of the information. For example, if there arenumerous unresolved conflicts in the transaction record and the trustscore of the users who entered the attribute information is low, thetrust score for the media content may be relatively low. If there are noconflicts in the transaction record and the attribute data is complete,the trust score for the media content may be relatively high.

The trust scores discussed above may be generated and stored indifferent ways in different embodiments. In some embodiments, the scoresmay be calculated and added to a record for a user or a song on theblockchain, and may be retrieved from the blockchain. In otherembodiments, in addition to or as an alternative to the data beingstored in the blockchain, the underlying data for the score may beavailable through the blockchain for any user or other entity todynamically calculate the score when added.

As discussed above, the information in the blockchain may be used toindicate a reliability of data for a media content on the blockchain.This reliability may be used in different ways. In some embodiments, thedetermination of reliability may be made as part of determining whetherto play an input song or other media, such as by determining whether themedia that is to be played is appropriately configured, with theblockchain, to ensure fair and full compensation is rendered to theartists or other rights-holders.

FIG. 7 is a flowchart of an illustrative method 700 for determiningwhether and how to access a media. The method 700 may be performed by adevice (e.g., device 106 of FIG. 1) operated by a user that is seekingto play or otherwise access a song or other media. For example, aconsumer device may be configured only to play music that willappropriately compensate artists. As another example, a music streamingservice, such as SoundCloud® or Spotify® may only authorize upload andplayback of music for which it can properly pay royalties. The method ofFIG. 7 may help ensure that the appropriate parties receive royalties orcredit when the song is played, for example, and help ensure thatincorrect information is not shared between users if the first user wereto share the song downloaded from the blockchain with another user.

The method 700 may begin by receiving an instruction to access mediacontent in step 702. For example, the device or service may receive afile wrapper with an instruction to play the song to which the wrapperrelates. As another example, the system may receive a request from amusic player to download a song stored on the blockchain, or a requestto access royalty payment information for a song stored on theblockchain.

In step 704, the system may verify that information on the media contentis stored in the blockchain. If it is not, and/or the system does nothave access to it, the method may end, for example by providing aresponse to the system that provided the instruction and/or byterminating the request. If the system verifies that the media contentis stored on the blockchain, meaning that information regarding themedia content exists on the blockchain, such as finding a uniqueidentifier corresponding to the media content on the blockchain, thesystem may proceed to step 706.

In step 706, the system may evaluate the reliability of informationregarding the media content on the blockchain. Evaluating thereliability of information may comprise accessing the trust score forthe media content, updating the trust score for the media content, orcreating a trust score for the media content. This may also includeretrieving data stored in the blockchain or in a file wrapper todetermine if criteria are met, such as whether more than the minimumpermissible characterization is stored, or if a particular attribute isstored. For example, a determination may be made of whether a royaltypayment action is fully specified.

In step 708, the system may compare the trust score for the mediacontent to a threshold value, or otherwise make a determination of thereliability of the information regarding the media content based on aresult of the evaluating of block 706. If the information is deemedunreliable, for example if the trust score falls below the thresholdvalue, the system may decline providing access to the media content. Ifthe information is deemed reliable, for example if the trust score fallsabove the threshold value, the system may proceed to step 710.

In step 710, the system may identify from the blockchain, or a filestoring blockchain information, action to be taken when the media isaccessed, based on the instructions received to access the media. Forexample, if the instruction received is to access royalty information,the system may identify the corresponding royalty information for themedia content in the attributes characterizing the media. The royaltyinformation may include an identification of a party to notify of aroyalty-triggering event (e.g., a PRO), an amount to pay, and/or anidentification or what events trigger a royalty.

In step 712, the system may access the media content on the blockchain,or access the information regarding the media content on the blockchain.For example, the system may retrieve the royalty information for themedia content and provide it to the system that issued the instruction,or the system may provide a means for the system that issued theinstruction to access the media data corresponding to the media content.The system may also take the action specified by the blockchain, such asnotifying a party of a royalty triggering event and/or sending orrecording a royalty payment.

Techniques operating according to the principles described herein may beimplemented in any suitable manner. Included in the discussion above area series of flow charts showing the steps and acts of various processesthat operate a distributed data storage system for media content. Theprocessing and decision blocks of the flow charts above represent stepsand acts that may be included in algorithms that carry out these variousprocesses. Algorithms derived from these processes may be implemented assoftware integrated with and directing the operation of one or moresingle- or multi-purpose processors, may be implemented asfunctionally-equivalent circuits such as a Digital Signal Processing(DSP) circuit or an Application-Specific integrated Circuit (ASIC), ormay be implemented in any other suitable manner. It should beappreciated that the flow charts included herein do not depict thesyntax or operation of any particular circuit or of any particularprogramming language or type of programming language. Rather, the flowcharts illustrate the functional information one skilled in the art mayuse to fabricate circuits or to implement computer software algorithmsto perform the processing of a particular apparatus carrying out thetypes of techniques described herein. It should also be appreciatedthat, unless otherwise indicated herein, the particular sequence ofsteps and/or acts described in each flow chart is merely illustrative ofthe algorithms that may be implemented and can be varied inimplementations and embodiments of the principles described herein.

Accordingly, in some embodiments, the techniques described herein may beembodied in computer-executable instructions implemented as software,including as application software, system software, firmware,middleware, embedded code, or any other suitable type of computer code.Such computer-executable instructions may be written using any of anumber of suitable programming languages and/or programming or scriptingtools, and also may be compiled as executable machine language code orintermediate code that is executed on a framework or virtual machine.

When techniques described herein are embodied as computer-executableinstructions, these computer-executable instructions may be implementedin any suitable manner, including as a number of functional facilities,each providing one or more operations to complete execution ofalgorithms operating according to these techniques. A “functionalfacility,” however instantiated, is a structural component of a computersystem that, when integrated with and executed by one or more computers,causes the one or more computers to perform a specific operational role.A functional facility may be a portion of or an entire software element.For example, a functional facility may be implemented as a function of aprocess, or as a discrete process, or as any other suitable unit ofprocessing. If techniques described herein are implemented as multiplefunctional facilities, each functional facility may be implemented inits own way; all need not be implemented the same way. Additionally,these functional facilities may be executed in parallel and/or serially,as appropriate, and may pass information between one another using ashared memory on the computer(s) on which they are executing, using amessage passing protocol, or in any other suitable way.

Generally, functional facilities include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types. Typically, the functionalityof the functional facilities may be combined or distributed as desiredin the systems in which they operate. In some implementations, one ormore functional facilities carrying out techniques herein may togetherform a complete software package. These functional facilities may, inalternative embodiments, be adapted to interact with other, unrelatedfunctional facilities and/or processes, to implement a software programapplication.

Some exemplary functional facilities have been described herein forcarrying out one or more tasks. It should be appreciated, though, thatthe functional facilities and division of tasks described is merelyillustrative of the type of functional facilities that may implement theexemplary techniques described herein, and that embodiments are notlimited to being implemented in any specific number, division, or typeof functional facilities. In some implementations, all functionality maybe implemented in a single functional facility. It should also beappreciated that, in some implementations, some of the functionalfacilities described herein may be implemented together with orseparately from others (i.e., as a single unit or separate units), orsome of these functional facilities may not be implemented.

Computer-executable instructions implementing the techniques describedherein (when implemented as one or more functional facilities or in anyother manner) may, in some embodiments, be encoded on one or morecomputer-readable media to provide functionality to the media.Computer-readable media include magnetic media such as a hard diskdrive, optical media such as a Compact Disk (CD) or a Digital VersatileDisk (DVD), a persistent or non-persistent solid-state memory (e.g.,Flash memory, Magnetic RAM, etc.), or any other suitable storage media.Such a computer-readable medium may be implemented in any suitablemanner, including as computer-readable storage media 806 of FIG. 8described below (i.e., as a portion of a computing device 800) or as astand-alone, separate storage medium. As used herein, “computer-readablemedia” (also called “computer-readable storage media”) refers totangible storage media. Tangible storage media are non-transitory andhave at least one physical, structural component. In a“computer-readable medium,” as used herein, at least one physical,structural component has at least one physical property that may bealtered in some way during a process of creating the medium withembedded information, a process of recording information thereon, or anyother process of encoding the medium with information. For example, amagnetization state of a portion of a physical structure of acomputer-readable medium may be altered during a recording process.

In some, but not all, implementations in which the techniques may beembodied as computer-executable instructions, these instructions may beexecuted on one or more suitable computing device(s) operating in anysuitable computer system, including the exemplary computer system ofFIG. 1, or one or more computing devices (or one or more processors ofone or more computing devices) may be programmed to execute thecomputer-executable instructions. A computing device or processor may beprogrammed to execute instructions when the instructions are stored in amanner accessible to the computing device or processor, such as in adata store (e.g., an on-chip cache or instruction register, acomputer-readable storage medium accessible via a bus, acomputer-readable storage medium accessible via one or more networks andaccessible by the device/processor, etc.). Functional facilitiescomprising these computer-executable instructions may be integrated withand direct the operation of a single multi-purpose programmable digitalcomputing device, a coordinated system of two or more multi-purposecomputing device sharing processing power and jointly carrying out thetechniques described herein, a single computing device or coordinatedsystem of computing device (co-located or geographically distributed)dedicated to executing the techniques described herein, one or moreField-Programmable Gate Arrays (FPGAs) for carrying out the techniquesdescribed herein, or any other suitable system.

FIG. 8 illustrates one exemplary implementation of a computing device inthe form of a computing device 800 that may be used in a systemimplementing the techniques described herein, although others arepossible. It should be appreciated that FIG. 8 is intended neither to bea depiction of necessary components for a computing device to operate inaccordance with the principles described herein, nor a comprehensivedepiction.

Computing device 800 may comprise at least one processor 802, a networkadapter 804, and computer-readable storage media 806. Computing device800 may be, for example, a desktop or laptop personal computer, apersonal digital assistant (PDA), a smart mobile phone, a server, or anyother suitable computing device. Network adapter 804 may be any suitablehardware and/or software to enable the computing device 800 tocommunicate wired and/or wirelessly with any other suitable computingdevice over any suitable computing network. Computer-readable media 806may be adapted to store data to be processed and/or instructions to beexecuted by processor 802.

The data and instructions stored on the one, two, or morecomputer-readable storage media 1806 may comprise computer-executableinstructions implementing techniques described herein. In the example ofFIG. 8, computer-readable storage media 806 stores computer-executableinstructions implementing various engines and storing variousinformation as described above. Computer-readable storage media 806 maystore an ingestion facility 808 that, when executed on the processor(s)802, implements an a system for ingesting media content.Computer-readable storage media 806 may also store an attribute updatefacility 810 that, when executed on the processor(s) 802, implements anattribute update engine that carries out an update of the attributes ofa media content, using any of the exemplary techniques described herein.A score facility 812 may be stored on the computer-readable storagemedia 806. The score facility 812, when executed by the processor(s)802, implements a score facility that carries out a score creation andupdates for users and media content. A distributed data store 814 may bestored on the computer-readable storage media 806. The distributed datastore 814 may include any of the distributed storage systems discussedabove. As should be appreciated from the above discussion of techniquesthat may be used may not use all of the components listed herein.Additionally, while the score facility 812 is illustrated as separatefrom the attribute update facility 810, in some embodiments the scorefacility 812 may form a part of the attribute update facility 810. Whilethe example of FIG. 8 illustrates multiple facilities 808, 810, 812, and814 embodiments are not limited to implementing all of these facilitiesor implementing all of these facilities together on one computingdevice. Rather, embodiments may implement any suitable facility orcombination of facilities in any suitable system including one or moredevices.

Embodiments have been described where the techniques are implemented incircuitry and/or computer-executable instructions. It should beappreciated that some embodiments may be in the form of a method, ofwhich at least one example has been provided. The acts performed as partof the method may be ordered in any suitable way. Accordingly,embodiments may be constructed in which acts are performed in an orderdifferent than illustrated, which may include performing some actssimultaneously, even though shown as sequential acts in illustrativeembodiments.

Use of ordinal terms such as “first,” “second,” “third,” etc., in theclaims to modify a claim element does not by itself connote anypriority, precedence, or order of one claim element over another or thetemporal order in which acts of a method are performed, but are usedmerely as labels to distinguish one claim element having a certain namefrom another element having a same name (but for use of the ordinalterm) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limiting. The use of“including,” “comprising,” “having,” “containing,” “involving,” andvariations thereof herein, is meant to encompass the items listedthereafter and equivalents thereof as well as additional items.

The word “exemplary” is used herein to mean serving as an example,instance, or illustration. Any embodiment, implementation, process,feature, etc. described herein as exemplary should therefore beunderstood to be an illustrative example and should not be understood tobe a preferred or advantageous example unless otherwise indicated.

Having thus described several aspects of at least one embodiment, it isto be appreciated that various alterations, modifications, andimprovements will readily occur to those skilled in the art.Accordingly, the foregoing description and drawings are by way ofexample only.

1. A method for maintaining a distributed data store storing informationregarding a plurality of media contents and a record of interactionswith the plurality of media contents, the method comprising: determininga reliability of information input by a user to the distributed datastore, wherein determining the reliability comprises: in response todetermining that the user has asserted an identity, determining whetherthe user has input to the distributed data store information consistentwith the identity; retrieving first information on one or morerelationships, existing outside of the distributed data store, betweenthe user and one or more other users of the distributed data store;retrieving second information on subsequent action taken on informationregarding media content input by the user to the distributed data store,wherein the subsequent actions include actions by other users confirmingor challenging the information input by the user; and calculating areliability metric for the user based on whether the user has assertedan identity and input information consistent with the identity, thefirst information on the one or more relationships between the user andthe one or more other users, and the second information on thesubsequent action.
 2. The method of claim 1, wherein determining whetherthe user has input information consistent with the identity comprisesdetermining whether a social media profile input by the user isconsistent with the identity.
 3. The method of claim 2, whereinretrieving first information on one or more relationships comprisesretrieving information from the social media profile on one or morerelationships between the user and social media profiles of the one ormore other users.
 4. The method of claim 1, wherein determining whetherthe user has input information consistent with the identity comprisesdetermining whether the user has input an employer email addressconsistent with the identity.
 5. The method of claim 1, whereindetermining whether the user has input information consistent with theidentity comprises determining whether a financial account of the useris consistent with the identity.
 6. The method of claim 1, wherein: thedetermining the reliability is performed by a device that is to access amedia content, and a record for the media content on the distributeddata store indicates the record was initially created by and/or modifiedby the user; the method further comprises: comparing, with the device,the calculated reliability metric to a threshold, and determiningwhether to access media content related to the user based at least inpart on a result of the comparing.
 7. The method of claim 1, furthercomprising: storing the calculated reliability metric in the distributeddata store at least in association with the user.
 8. The method of claim1, further comprising: regulating an ability of the user to modify oneor more records on the distributed data store based on the calculatedreliability metric.
 9. The method of claim 8, wherein the regulatingfurther comprises issuing a number of tokens to the user based at leastin part on the calculated reliability metric.
 10. The method of claim 1,further comprising: determining a reliability metric for a media contentfor which the record created and/or modified a record on the distributeddata store based at least in part on the calculated reliability metric.11-27. (canceled)